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Resource Allocation in Packet Network 
Field of the Invention 

This invention relates to resource allocation in packet switching 
5 networks, especially in IP networks. 

Background of the Invention 

The tasks of a network are divided into several entities, called 
layers, that handle specified tasks. For example, it is possible to separate 

10 four distinct layers in IP networks: the Link, Network, Transport and 
Application layer (Figure 1). In known IP networks signaling handles mainly 
channel related matters, such as connection set up and connection break off, 
while management handles element configuration, monitoring, and error 
messages, for example. 

15 The Network layer is the heart of the IP network. It specifies the 

format of the Internet packets, called datagrams. Datagrams contain 
specified fields, such as the destination and the source of the datagram 
packet. Information is sent by packets which contain the information for 
routing the packet to the right destination element. The routers in the network 

20 must know how to route the packets to the right receiver, so the IP layer also 
includes a set of rules defining how the packets should be processed. 

The Transport layer specifies means for identifying the ultimate 
destination, i.e. the application in the receiving network element. The two 
most common ways to handle the transport of a packet are UDP (User 

25 Datagram Protocol) and TCP (Transmission Control Protocol). UDP is an 
unreliable connectionless delivery system, while TCP provides reliable 
delivery. That means that the TCP sender and receiver must agree that a 
connection is desired. TCP requires an acknowledgment message from the 
receiver before the sender is allowed to send more packets. TCP uses a 

30 sliding window technique to send acknowledgments. The sliding window 
indicates the number of packets that a sender can send without receiving an 
acknowledgment. When the sender gets the acknowledgment concerning 
the first packet sent, the window slides, making it possible to send a new 
packet. The receiver can advise the sender what the preferable size for the 

35 sliding window is (specifying the receiver's current buffer size). In other 
words, the sliding window technique can be used for flow control. 
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The Application layer handles a variety of tasks, such as e-mail 
and file transport. This layer also contains SNMP (Simple Network 
Management Protocol) that handles matters such as configuration of network 
elements and monitoring. 
5 The Link layer consists of a physical network, such as Ethernet 

and ATM. In ATM networks, for example, it is possible to group several 
virtual channels together into a virtual path, that is an individual manageable 
object. 

The disadvantage of the known solutions is that there is no 
10 common way to handle the allocation of network resources in a packet 
network, such as an IP network. Known resource allocations are dependent 
on network characteristics, and thus run on the Link layer. In other words, 
resource allocation is possible only in the same physical network, such as 
ATM, but it is impossible to negotiate resource allocation between two 
15 network elements in different networks using one common environment. Due 
to the lack of a common resource allocation method, it is complicated to 
agree on traffic allocation, for example between operators. Dynamic 
allocation can also be tedious. The objective of the invention is to eliminate 
these disadvantages. This is achieved in a way described in the claims. 

20 

Summary of the Invention 

The idea of the invention is to negotiate the resource allocation 
between two network elements on the Application or Transport layer level so 
that the negotiation is possible over the network, even if the network 

25 comprises several physically different networks. To determine the 
transmission capacity for the allocation, the sending element must first send 
a request message with a proposal for the capacity and media types. The 
receiving element either accepts the proposal or makes a new proposal by 
changing the parameter values so that they are acceptable from the point of 

30 view of the receiver, and sends a response to the sending element. Based 
on the response from the receiving element, the sending element the either 
accepts or rejects the allocation and informs the receiving element of its 
decision by sending a confirmation. 



35 
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Brief Description of the Drawings 

In the following the invention is described in more detail by means 
of figures 2 - 7 in the attached drawings, where 



Figure 1 illustrates layers of a packet switching network, 
Figure 2 illustrates a capacity allocation according to the invention, 
Figure 3 depicts a capacity allocation request according to the invention, 
Figure 4 depicts a response for the capacity allocation request according to 
the invention, 

Figure 5 depicts a pending message according to the invention, 
Figure 6 depicts a release of the resource allocation according to the 
invention. 

Figure 7 illustrates a time-out for a request. 



15 Detailed Description of the Invention 

A communication network consists of many different elements, 
such as exchanges and switches in traditional PSTN networks, base stations 
and mobile switching centers in mobile networks, and bridges and routers in 
datacommunication networks. Networks also contain data and signaling 

20 channels between the different elements. A packet switching IP network is 
more like a virtual network, which is built over several physical networks. 

Resource allocation involves a transmission capacity agreement 
between two network elements. The transmission capacity agreement can 
contain, for example, the number of channels to be used, the type of the 

25 channels (audio, data, fax, etc.) and the bandwidth of the channels. 
Generally, existing technology does not include a way to negotiate resource 
allocation between different network elements over a variety of different 
networks. In order that resource allocation is possible in a packet network, 
there must be a common way to negotiate allocations. 

30 Figure 2 depicts an example of a packet switching virtual network 

(IP network). The virtual network can contain many subnetworks, but 
because the virtual network forms a common way for transmission, it is 
reasonable to picture the network as one entity. The virtual network can have 
connections to other networks, such as PSTN. In this context, it is also 

35 reasonable to name the network elements in a uniform way. Let's call the 
elements endpoints. In real physical networks endpoints are exchanges, 
routers, switching centers, etc. 
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Figure 2 shows an example of how a negotiation of the resource 
allocation between endpoint 1 and endpoint 2 is made according to the 
invention. The goal is to agree on the biggest possible traffic capacity 
between the endpoints. The negotiation channel between the endpoints is 
5 preferably formed by signaling channels in the IP network. The network 
handles routing of the signaling, and it is not a part of the invention. An 
endpoint is responsible for handling certain traffic capacity needs from the 
part of the network that is connected to the endpoint (for example a local 
exchange). The endpoint can also be responsible for handling by-pass traffic 

10 (for example a router). Figure 2 depicts the situation where endpoint 1 and 
endpoint 2 handle the traffic of their respective subnetworks. The negotiation 
between endpoints 1 and 2 starts when endpoint 1 sends a request for 
capacity needs. The request contains the number of different channel types 
required, for example 500 audio channels, 500 data channels and 300 fax 

15 channels. Endpoint 2 receives the request and compares it to it's own 
resources. If endpoint 2 has enough capacity to handle the amount 
requested, it accepts the request and sends back a proposal with the same 
capacity values. If endpoint 2 does not accept the request, it processes the 
maximum acceptable values that are still smaller than the values in the 

20 request, for example 300 audio channels, 200 data channels and 100 fax 
channels, and sends the proposal with new values back to endpoint 1. 
Endpoint 1 receives the proposal, makes a decision on the acceptability of 
the resource allocation, and sends a confirmation comprising the decision to 
endpoint 2. 

25 The function of the negotiation process according to the invention 

can be divided into two mandatory portions: Initial Negotiation and Re- 
negotiation, and two optional portions: Pending Option and Removing 
Option. 

The Initial Negotiation includes the request, the response, and the 
30 confirmation as described above. The format of the request is depicted in 
Figure 3. The request, like the other messages according to the invention as 
well, is sent over TCP or UDP, i.e. in the data field of these protocols. 
Version (4 bits) is a model version of the format. Version makes an 
adaptation possible between different updated model versions. Message (8 
35 bits) identifies the message and allows fast interpretation of the message 
content. Length (2 octets) tells the length of the message in octets. 
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Reservation (4 bits) is reserved for future use. Initial Token (4 octets) 
identifies the sender who has initialized the request. Initial Ticket (4 octets) is 
a parameter that is set by the sender. The receiver records the value of the 
Initial Ticket. The meaning of the Initial Ticket is to identify the negotiation. 
5 Media Type identifies the desired media type, i.e. audio, video, fax, or data. 
Media Property (2 octets) tells the bandwidth needed for the media type. 
Tariff (1 octet) contains tariff information related to capacity reservation. 
Capacity (4 octets) tells the capacity reserved in units of media used 
(number of channels). Time for Validity is the time value indicating how long 
10 the negotiated capacity is valid. Media Type and Capacity are mandatory 
fields, whereas Media Property, Tariff, and Time for Validity are optional 
fields. 

Response (Figure 4) contains the same fields as the request 
format except that Initial Token is replaced by Response Token, and there is 

15 a new field: Second Party Ticket. The Response Token identifies the sender 
of the initial request. The Second Party Ticket is set by the receiver and 
recorded by the sender of the initial request. The Second Party Ticket 
identifies the capacity negotiation, and it is used for further negotiation to 
change the resource allocation. The Capacity remains the same as in the 

20 Request if the receiver accepts it, otherwise the receiver uses it's own 
values. 

The format of the confirmation is the same as the format of the 
response. The sender of the initial request sends the confirmation to the 
receiver with parameters copied from the response. If the sender does not 

25 accept the values set by the receiver, it can refill the Capacity parameters to 
zero value indicating that the negotiation was unsuccessful. Later on, if 
needed, the sender can initialize a new negotiation. 

Re-negotiation is used when either one of the endpoints wants to 
change the Capacity parameters. The endpoint that starts the negotiation 

30 must set Initial Ticket and Response Token to the same values as used in 
the initial negotiation, otherwise messages are silently discarded. The 
negotiation progresses the same way as in the initial negotiation. 

Pending is an optional feature (Figure 7) and it makes it possible 
to inform the initial sender of the request that the request is under process, 

35 and Response will be returned before the indicated time-out. In other words, 
Pending tells the time-out for the Request. The receiver sends Pending after 



WO 01/86910 



PCT/FI01/00401 



6 



receiving Request, but before sending Response. Figure 5 depicts the format 
of Pending. A new field is Time for Pending. It is the time value for how long 
the delay in responding is supposed to last. The rest of the fields are the 
same as described above: Version, Message, Length, Reservation, 
5 Response Token, Initial Ticket, and Second Party Ticket. 

Removing is also an optional feature, and it is used when one of 
the endpoints wants to remove the capacity reserved between the endpoints. 
The format of Removing is depicted in Figure 6. There is one new 
parameter, Time for Release. The other parameters are familiar from the 

10 above. Time for Release is the time-out value that is needed before the 
resources negotiated are available. The removing function consists of two 
messages: Release and Release Acknowledged. The endpoint that starts 
Removing sends a Release message to the other endpoint. The Initial Ticket 
and Response Ticket fields in the release message are in the same values 

15 as in the initial negotiation, otherwise the message is discarded. The other 
endpoint sends back a Release Acknowledged message which does not 
include Time for Release information. 

Table 1 collects the different messages together. Table 2 
describes the different parameters. 

20 



Table 1, Messages 



Message 
Identifier 


Message 


Description 


0x1 


Request 


Initial request for Capacity 


0x2 


Response 


Acknowledgment for initial request 


0x3 


Confirm 


Final confirmation of the Request 


0x4 


Pending 


Indicates that the Request is being processed 
and the handling of the Request may takes 
longer than usual. 


0x5 


Release 


Releases reservation of capacity immediately or 
delayed, according of the Time for Validity 
parameter 


0x6 


Release 
Ack. 


Confirms the Release operation proposed by 
other endpoint. 



WO 01/86910 



PCT/FI01/00401 



Parameter 


Description 


Version (4 bits) 


Protocol version tells the updated version of the 
protocol. 


Message (8 octet) 


Message identifier identifies type of message. 


Length (2 octets) 


Tells Length of Message in octets starting from header. 


Reserved (4 bits) 


A field reserved for future use. 


Initial TnU'ian (A 

lllllldl 1 U^CI 1 \H 

octets) 


luciiiuica uiiyin or iric pany wnicn nas initialized 
request 


ResponseToken (4 


Identifies origin of the party which has initialized 
rGsponsG 


Initial Ticket (4 


Identifies capacity negotiation request and is used with 

ft irthor nonntistiiftnc in lofor if rmninal wohi^c ara 
1UIHIGI HcyUUdllUI lo III IdLCI II UIILJIIIdl VdlUcs die 

changed. 


a, rdl ly 1 lOftcl yfr 

octets) 


Identifies capacity negotiation for 2 nd party it is used 
with further negotiations by initiated 2 nd party if original 

vcjiuco die ouctiiycu. 


Media Type (1 


Identifies the Media type. Possible values are Audio, 
Video Fax or Data 


Media Property (2 
octets) 


This field gives more detailed information of bandwidth 
needed for media type 


Tariff (1 octet) 


The parameter tells tariff information related to the 

rpcpr\/f=*rl mpHia nanknnc* 
icoci vcu nicuic* [Jdu^yc 


Capacity (4 octets) 


Parameter tells capacity reserved for Media units i.e. 
number of calls, ports or connections. 


Time for Validity (4 
octets) 


The time value in seconds for how long the negotiated 
capacity is valid. 


Time for Pending 
(4 octets) 


The time value in seconds for how long pending is 
estimated to last. 


Time for Release 
(4 octets) 


The time value in seconds for how long the negotiated 
capacity is available. 



The invention makes it possible to negotiate resource allocation 
between two endpoints over a network, comprised of several physically 
5 different networks. Routing is made as before in a packet switching network, 
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but now there is a negotiation for the resource allocation. The benefits of the 
negotiation are that it makes transmission more certain, makes it possible to 
direct transmission traffic, and especially makes one common way for 
handling negotiations, although there can be several different physical 
5 networks between the endpoints. 

An endpoint handles transmission capacity as one pool from 
where it is possible to make reservations for traffic to a certain endpoint, and 
so the traffic load is easier to divide evenly to different directions. Resource 
allocations can be changed dynamically, thus an endpoint can adapt easily 

10 to different situations, such as more telephone calls in evenings, special 
services like telephone calls to a popular TV show, and a company's needs 
to transmit huge amounts of data during the day time. The invention also 
makes it possible to negotiate resource allocation between two operators. In 
this situation a SLA (Service Level Agreement) is needed between the 

1 5 operators. 

The situation in Figure 2 where there is a negotiation for resource 
allocation between endpoint 1 and endpoint 2, it can be done with one 
negotiation for all media types. The Length field in message packets tells the 
total length of the negotiation message. In other words, data, audio, and fax 

20 types have their own message packets inside the negotiation message, such 
as a Request message. The bandwidth of a media type can be determinated 
in the Media Property field. Consequently, the total bandwidth needed for an 
allocation is the bandwidth of a media type multiplied by the value of the 
Capacity field. The invention is especially useful when the negotiation 

25 concerns huge amount of channels. 

The invention is described above at the Application layer level, but 
it is clear that the invention can be implemented at the Transport layer level 
as well. The invention can be combined with other protocols as well. For 
example, tunneling over H. 323, Q.BICC, and SIGTRAN are possible by 

30 embedding the resource allocation information into the payload information. 
Although the invention is described more like a separate protocol, it can be 
integrated as a portion of another protocol. It is evident that the invention is 
not restricted to the above-mentioned examples, but that it can be used in 
other implementations within the scope of the inventive idea. 



35 
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Claims 

1. A method for allocating transmission resources between two 
network elements in a packet switching network, characterized in that 
5 the resources are allocated by exhanging messages above a network layer 
between the two networks elements by: 

- sending a request message, from the first network element to the 
second network element, the request message including the value 
of the capacity that the first element desires to allocate for use 

1 0 between the two network elements, 

- receiving the request message in the second network element 
and finding a capacity value which is acceptable from the point of 
view of the second network element and not greater than the 
value received in the request message, 

15 - sending a response message from the second network element 

to the first network element, the response message including the 
capacity value found in the second network element, 

- receiving the response message in the first network element and 
making a decision, based on the capacity value received in the 

20 response message, on the acceptability of the resource allocation, 

and 

- sending a confirmation message from the first network element 
to the second network element, the confirmation message 
including data indicating the decision made. 

25 2. A method according to claim ^characterized in that the 

request message further includes: 

- a type of the capacity, and 

- a token for identifying the request. 

3. A method according to claim 2, characterized in that the 
30 request message further includes: 

- a bandwidth of the type of the capacity, 

- tariff information related to the capacity, and 

- time information indicating how long the allocation is to be valid. 

4. A method according to claim ^characterized in that the 
35 response message further includes: 

- a type of the capacity to be allocated for use, 
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- a token for identifying the request, and 

- a token for identifying the allocation session. 

5. A method according to claim 4, characterized in that the 
response message further includes: 

5 - a bandwidth of the type of the capacity, 

- tariff information related to the capacity to be allocated for use, 
and 

- time information indicating how long the allocation is to be valid. 

6. A method according to claim ^characterized in that the 
10 confirmation message includes: 

- a type of the capacity to be allocated for use, 

- the accepted capacity value, 

- a token for identifying the request, and 

- a token for identifying the allocation session. 

15 7. A method according to claim 6, characterized in that the 

confirmation message further includes: 

- a bandwidth of the type of the capacity, 

- tariff information related to the capacity to be allocated for use, 
and 

20 - time information indicating how long the allocation is valid. 

8. A method according to claim 1, characterized in that 
before sending the response message, the second network element sends a 
pending message to the first network element, the pending message 
including 

25 - a token for identifying the request, 

- a token for identifying the allocation session, and 

- time information indicating the maximum time period between 
the request message and the response message. 

9. A method according to claim 1, characterized in that the 
30 method further includes the steps of: 

- sending a release message from one network element to the 
other network element for releasing the allocation, 

- sending a release-acknowledged-message from the network 
element that received the release message to the network element that sent 

35 the release message. 
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1 0. A method according to claim 9, characterized in that 
the release message includes 

- a token for identifying the request, 

- a token for identifying the allocation session, and 

5 - time information for indicating how long the resource allocation is available. 
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